A. Field of the Invention
The present invention relates to the field of data communications, and more particularly to techniques for communicating media streams in voice-over-packet telecommunications.
B. Description of the Related Art
Data networks, such as the Internet, have grown in their reach and capability to the point where they provide a practical alternative infrastructure for performing many communications functions that are presently performed over the general switched telephone network (GSTN). Indeed, even voice communication, the communication function that led to the development of the GSTN, may be performed on data networks. A growing number of telephony services offer basic voice telephony using data networks. These services are typically known as “voice-over-packet” services because they involve using a packet-switched data network for at least a portion of a telephone call connection. One example of a voice-over-packet service is “voice-over-IP” (“IP” refers to “Internet Protocol”, a network protocol used for transporting data over the Internet).
Voice over IP (VoIP) uses one or more IP networks to set up phone calls and transport the voice data (media) in IP packets. The architectures and protocols of VoIP separate the media component and the call control component. The media component may use a media stream protocol, such as the Real-Time Protocol (“RTP”), to transport packetized voice data across the IP network between two media transport endpoints. The media component may also include interworking functions for translating between RTP-based media and other types of media transport (e.g., time-division multiplexed [“TDM”], asynchronous transfer mode [“ATM”], etc.). The call control component incorporates protocols, such as the Session Initiation Protocol (“SIP”) and Megaco, to set up, tear down, and manage calls in the IP network, and includes interworking functions for translation between IP-based control protocols and PSTN control protocols (e.g., SS7 and PRI).
The data packets communicated in VoP, and particularly in VoIP, systems typically include a header and a payload. The header typically contains control information, or information used by the system to route or otherwise process the packets. For example, the header typically contains the IP addresses of the sources and destinations of the packets. The payload typically contains the data being communicated in the packet. In general, the header portion is overhead and should be as small in size as possible. One measure of efficiency that may be used to evaluate particular systems is the payload-to-header size ratio of the packets being communicated. The higher the ratio, the more efficient the system.
The RTP endpoints of a VoIP call may be IP media devices (e.g., IP phones), Media Gateways for interworking between an IP network and a TDM network or another packet network (ATM, Frame, etc.), or any combination thereof. The connection established between a pair of RTP endpoints defines an RTP session (or more generally, a media session), and each unidirectional media flow in the session defines an RTP stream (or more generally, a media stream). That is, a simple, point-to-point voice call utilizes one RTP session, and two RTP streams (one in each direction). The complete, end-to-end call path of the media may traverse an IP network exclusively, or a combination of IP network and some other type of network (TDM, ATM, etc.).
Within the IP network, a device known as a softswitch is typically responsible for performing call control functions. A softswitch is a network device that implements peer-to-peer call control protocols, protocol interworking, device control of Media Gateways, and application interfaces for service creation and maintenance. Basic services performed on these interfaces include directory mapping, billing and records, and authentication.
As the reach of VoIP deployments and the use of VoIP service grow, the volume of VoIP traffic on IP networks will also grow. The efficiency of the media transport will become increasingly important to network bandwidth utilization, packet processing, and their impact on quality. Factors that effect efficiency include data compression, the ability to detect silence intervals during a voice call and exclude them from RTP transport, and the size ratio of payload-to-header in the IP packets. The ability to exclude silence intervals from transport will always increase overall efficiency. However, depending upon how voice samples are packetized, the other two factors may have competing effects on efficiency. Considering a fixed IP header size and fixed RTP header size, then the gain from data compression is offset by some factor by the decrease in RTP payload size. Similarly, a decrease in sampling time, desirable for reducing delay, results in a smaller frame size, and again a low payload-to-header ratio.
Increasing the payload-to-header ratio can be achieved by some combination of larger payload size and smaller header size. There are a number of header compression algorithms available for decreasing the header size. However, for a single RTP payload, increasing the frame size implies less (or no) media compression, and/or longer packetization times. For a device that terminates many RTP streams, such as a Media Gateway, a better approach to increasing the payload size is to multiplex the RTP packets from multiple RTP streams in a single IP packet. In addition, further gains in both network bandwidth utilization and IP packet traffic reduction may be realized by combining both header compression and RTP multiplexing. However, multiple RTP streams can only share a single IP packet if they already share the same source and destination IP addresses. In general, there is no guarantee that multiple RTP streams from the same source IP address are ever destined to the same destination IP address. Accordingly, RTP multiplexing and header compression may not be used enough to realize the gains they promise.
It would be desirable to improve bandwidth optimization on VoIP networks by more frequently and more consistently implementing header compression and RTP (or stream) multiplexing techniques.